思考企業應用程式最久遠的方法之一，就是將其視為對外在世界事件做出反應的系統。這是一種思考方式，在 80 年代後半期的結構化設計社群中確立。現在您會在「事件驅動架構」的標語下聽聞這種說法。在 2000 年代中期，我開始為這類系統收集一些模式，但從那以後一直無法將它們轉化為更有實質性的東西。儘管它們粗糙且準備不足，但我確實認為它們提供了一些關於事件協作性質的有用想法，引入了「事件來源」一詞，使用平行模型來表示世界的假設狀態，以及如何使用協定調度器來組織網域邏輯。

去年年底，我參加了 Thoughtworks 同事的研討會，討論「事件驅動」應用程式的性質。在過去幾年中，我們建構了許多大量使用事件的系統，它們經常受到讚揚，也經常受到批評。我們的北美辦公室組織了一場高峰會，來自世界各地的 Thoughtworks 高級開發人員齊聚一堂，分享想法。

高峰會最大的成果是認識到，當人們談論「事件」時，他們實際上指的是一些截然不同的事情。因此，我們花了很多時間試圖找出一些有用的模式。本備忘錄簡要總結了我們識別出的主要模式。

LMAX 是新的零售金融交易平台。因此，它必須低延遲處理許多交易。此系統建構在 JVM 平台上，並以業務邏輯處理器為中心，該處理器可以在單一執行緒上每秒處理 600 萬筆訂單。業務邏輯處理器完全在記憶體中執行，使用事件來源。業務邏輯處理器周圍環繞著 Disruptors，這是一個並行元件，實作一個無需鎖定的佇列網路。在設計過程中，團隊得出結論，使用佇列的高效能並行模型的最新方向與現代 CPU 設計根本不符。

CQRS 代表命令查詢責任分離。這是由 Greg Young 最先描述的模式。其核心概念是，您可以使用不同的模型來更新資訊，而不是使用您用來讀取資訊的模型。在某些情況下，這種分離可能很有價值，但請注意，對於大多數系統而言，CQRS 會增加風險複雜性。

這是某種應用程式，我遇到過好幾次。應用程式主要是報告應用程式，可提供使用者某個事項狀態的即時資訊。這是一個主動式應用程式，使用者可以高度控制他們正在檢視的內容類型，他們可以深入探討特定區域，並通常操控其顯示；然而，它仍然至少主要是唯讀應用程式。

當人們啟動企業應用程式時，最早出現的問題之一是「我們如何與資料庫對話」。這些天，他們可能會提出一個稍微不同的問題「我們應該使用哪種類型的資料庫 - 關係式或這些 NOSQL 資料庫之一？」。但還有另一個問題需要考慮：「我們是否應該使用資料庫？」